toolchain: mirror hi3516cv100 MPP headers into hisilicon SDK tarballs#2108
Merged
Conversation
The Hisilicon vendor SDKs for hi3520dv200, hi3516av100, hi3516cv200, hi3516cv300, hi3516cv500, hi3516ev200, hi3519v101, hi3536dv100 ship their binary blobs (`kmod/`, `lib/`, `script/`) under `general/package/hisilicon-osdrv-<family>/files/` but none of them include the `include/` headers needed to compile MPP userspace code against `libmpi.so`. Only `hisilicon-osdrv-hi3516cv100/files/include/` carries the canonical Hisilicon MPP header set (62 files: `hi_type.h`, `hi_comm_sys.h`, `mpi_sys.h`, `hifb.h`, …), and that set is ABI-compatible across the family — the literal `/***** 3520 ADDed *****/` comment block in `hi_comm_vo.h` confirms 3520 compatibility patches were applied to it upstream. Consequence today: applications built against the downloaded `toolchain.hisilicon-<family>.tgz` (e.g. hifb-using utilities, OSD helpers, video pipeline daemons targeting Hisilicon SoCs other than hi3516cv100) must each bundle their own copy of the cv100 headers. We hit this when prototyping an `hifb_demo` for hi3520dv200 — ~20 headers had to be carried inside the package source tree. Extend `BUNDLE_SDK` to mirror the cv100 header set into `sdk/include/` whenever the target is a Hisilicon board that doesn't already ship its own `include/` directory. Strictly additive: cv100 itself is unaffected (its own `include/` is copied by the existing `cp -a $OSDRV_DIR/*`), non-hisilicon boards are unaffected, and the new copy is a no-op if `hi3516cv100/files/include/` is ever removed. After this lands, the published `toolchain.hisilicon-hi3520dv200.tgz` (and siblings) will have `<sdk_top>/sdk/include/hi_type.h` etc. so a downstream consumer can `-I$(SDK)/sdk/include -L$(SDK)/sdk/lib -lmpi` without copying any headers around. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
BUNDLE_SDKin the top-levelMakefileso the publishedtoolchain.hisilicon-<family>.tgzcarries the Hisilicon MPP development headers under<sdk_top>/sdk/include/, alongside the per-boardsdk/lib/*.soblobs that are already bundled.BR2_OPENIPC_SOC_VENDOR=hisiliconand the board's owngeneral/package/hisilicon-osdrv-<family>/files/has noinclude/directory of its own. Today that covers hi3516av100, hi3516cv200, hi3516cv300, hi3516cv500, hi3516ev200, hi3519v101, hi3520dv200, hi3536dv100 — i.e. all in-tree Hisilicon OSDRV packages except hi3516cv100 itself.Why
The Hisilicon vendor SDK ships under
general/package/hisilicon-osdrv-<family>/files/for each chip. For every chip except hi3516cv100, that only includeskmod/,lib/,script/— no headers — so anyone writing MPP userspace today against the downloadedtoolchain.hisilicon-hi3520dv200.tgz(or any other family) has to bundle their own copy of the cv100 headers.The cv100 set (62 headers:
hi_type.h,hi_comm_sys.h,mpi_sys.h,hifb.h, …) is the canonical, ABI-compatible reference set across the Hisilicon MPP family.hi_comm_vo.heven carries a literal/***** 3520 ADDed *****/comment block confirming 3520-family compat patches were applied to it upstream.We hit this concretely when prototyping a small
hifb_demofor hi3520dv200 — had to copy ~20 headers into the demo source tree. With this change, a downstream consumer can just-I$(SDK)/sdk/include -L$(SDK)/sdk/lib -lmpiand link against the toolchain as-is.Test plan
toolchainworkflow (manually dispatched) rebuildstoolchain.hisilicon-hi3520dv200.tgz(and siblings) successfully.tar tzf toolchain.hisilicon-hi3520dv200.tgz | grep sdk/include/hi_type.hmatches a single entry.tar tzf toolchain.hisilicon-hi3516cv100.tgz | grep sdk/include/hi_type.hmatches a single entry (still — copied via the existing OSDRVcp -apath, NOT via the new branch).toolchainrelease for those boards (the new conditional doesn't fire).🤖 Generated with Claude Code